home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0031-Even more on GC-Jul89 < prev    next >
Encoding:
Text File  |  1989-07-12  |  4.2 KB  |  81 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  BURBECK.S    to LICHTY
  2.  
  3. Item    8580162                         9-July-89        19:32
  4.  
  5. From:   BURBECK.S                       Burbeck, Steve
  6.  
  7. To:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Even more on GC
  10.  
  11. Few programmers, even longtime users of systems with garbage collection (GC),
  12. give much thought to the issues underlying GC.  So let me try to open an
  13. alternative facet to the debate about performance, reference counting,
  14. generation scavenging, assignment operator overloading and language dependence.
  15.  Let's first consider the value of GC.  If GC is of little value, performance
  16. doesn't matter.  If we agree that GC is valuable, then we can debate about how
  17. much performance hit there might be.
  18.  
  19. GC encompasses two separate issues: garbage detection and memory compaction.
  20. The Mac memory manager already does the second.  But, except for Smalltalk and
  21. Lisp, the programmer must do the former: and to do so, (s)he must deeply
  22. understand the runtime dependencies between objects at the time the code is
  23. written.  Even in relatively simple cases, errors are all too common: the
  24. programmer often causes objects to be freed too soon, causing relatively prompt
  25. crashes, or fails to free them at all, thereby producing memory leaks which run
  26. the program out of memory at some unspecified time.  Memory leaks are a
  27. pernicious and often unrecognized problem.  For instance, the developers of
  28. ET++ (a C++ environment for Sun machines based loosely on MacApp) did a study
  29. of memory leakage.  They were horrified to find that as much as 70% of their
  30. memory was garbage!  And note that they had the "benefit" of constructors and
  31. destructors.  The problem may be even more acute with Object Pascal.
  32.  
  33. But a more important, if subtle, problem is that the programmer's need to
  34. easily be able to know when an object can be freed forces a restrictive style
  35. of object references.  Object references tend to be forced into simple tree
  36. structures with a few well defined roots (i.e., the document, the application,
  37. or a window).  Otherwise, it becomes very difficult to know when an object can
  38. safely be freed.  Imagine, for instance, that an object is referenced both by
  39. an instance variable (field) in some object and is also referenced by an entry
  40. in some collection object (e.g., a sorted list).  Should the programmer free
  41. the object when the list goes away, or when the other referencing object goes
  42. away.  In some specialized cases, the programmer knows which object will live
  43. longer.  But more often, the programmer simply must avoid the problem by not
  44. placing references in both places.  And more complex lattice structures of
  45. object references are completely out of the question without GC.  Yet, since
  46. most programmers have little if any experience with systems that have GC, few
  47. of them recognize how useful a freer pattern of object references can be.
  48.  
  49. So I would pose some questions:  How much of your development time is spent
  50. tracking down object-freeing bugs?  How many of you are sure you don't have
  51. memory leakage?  How many times have you wanted to keep a reference to an
  52. object in multiple places but were disuaded by the fact that you couldn't know
  53. when to free it? How many of you wished you had the kind of collection classes
  54. available in Smalltalk?
  55.  
  56.  
  57. Steve Burbeck
  58.  
  59.  
  60.  
  61.  
  62. PS -- some specific comments on previous links:
  63.  
  64. 1)  I doubt that assignment is significantly more common in hybrid languages
  65. than in Smalltalk.  Does anyone have any evidence to support such an assertion?
  66.  
  67. 2) Geoff, what do you mean by a language "designed for GC"?
  68.  
  69. 3) A nit: the problem is one of references to new objects being assigned to
  70. objects in "older" spaces.  In that case, the object may be alive even though
  71. no other "new" space object points to it.  A simple solution is to "promote"
  72. such objects out of the "new" space.
  73.  
  74. 4) I don't understand your assertion that gc is not appropriate for hybrid
  75. languages.  You might argue that the pattern of object creation and destruction
  76. on hybrid systems is inherently simple (perhaps because of compiler
  77. restrictions that make collections less useful), hence GC doesn't buy you much.
  78.  But if so, why are there so many bugs due to incorrect freeing of objects?
  79.  
  80.  
  81.